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A C N  Decision  Pules  la b i e 


AFIT / G L M / L  S  M /89S-5 


Abs t ract 

A  new  Air  Force  weapon  system,  if  delivered  beiore  the 
support  items  needed  to  sustain  i  +  s  use,  is  not  a  credible 
threat  or  deterrent.  To  ensure  concurrent  deliverv  of 
support  items  and  the  end  item,  provisioning  data,  used  to 
initiate  procurement  of  the  support  items,  is  processed  long 
before  production  of  the  end  item  is  completed.  Due  iargelv 
to  the  complexity  of  new  Air  Force  systems,  changes  to  the 
design  frequently  occur  after  the  original  provisioning  data 
i  s  submitted.  Design  Change  Notices  (DCN)  are  used  to 
notify  the  Air  Force  of  changes  that  have  occurred  to  the 
provisioning  data.  The  volume  of  changes  being  submitted 
threatens  to  overwhelm  the  Air  Force  pi o v i s i o n i n g  process 
and  obviate  the  advantage  of  processing  the  data  ear i v  to 
begin  with. 

Inis  researen  descrioes  l-CN's  and  ACM  processing  in  the 
Air  Force.  A  flow  chart  of  the  current  DCN  process 
illustrates  that  the  process  is  repetitive  and  inefficient, 
but  the  process  is  inextricably  linked  i. he  All  Force 

provisioning  data  system.  A  new  data  svstem  must  he 
developed  tn  solve  the  process  inefficiencies.  In  addition, 
many  DC\'s  that  are  being  submitted  and  processed  do  not 
impact  support  item  procurement.  These  must  he  identified 
and  edited  out  rat  her  than  be  processed  unnecessari i v 


v  i 


Ilf''11’'.  1  H  '  (  i  h  VI  It  h  S  I  \  a  1  K  !-  I  i  H 1  h  ",  H  \  ><  )■  ~i  \  I  I  M  i  s  l  |  .  I  i  \ 

I  .  IntTf'd'K  r  j  i .in 

Gen^r  a  i _ I_s  sy e 

i’u  i  t  ed  States  militarv  s  f  ra  r e?v  emphasises 
r  eciinv  i  og  i  <;  a  i  super i  (>r  i  ;  y  over  numerical  s  u  pe  r  i  n  r  i  r  .  The 
r  p . i s n n  i  p. g  g o p  s  t  ha r  a  r e  i  a  t  i  v e  f  e  w  T  <-> ' h n < i  i  1 1 a i  r- a  i  j  v  .niv-i!i,'«'i 
weapon  sysfpns  will  hp  able  t  o  n  verw’ne  i  m  nunv 
technologically  inferior  systems  .  an  i  nh^r^nt  risk  in  this 
approach  is  that  a  single  fa  i  i  are  in  a  system  t  ha  t  is 
pi  inneri  fn  cn'int  er  say.  f  went  v  svs+ems .  is  f  he  e  q  u  i  v  a  i  e  n  T  of 
twenty  system  failures  for  the  other  side.  ’weapon  s  vs  r sm 
support .  ma i n I enanoe .  snares,  and  support  equ ioment  is 
. .  s  ne  r  i  a  i  i  v  o  r  i  t  i  oa  i  in  a  r  e<*hno  i  ogi  ra  i  suner  i  or  i  t  v  s  *•  ?  \  *  fun- . 

Prov  i  s  i  on  i  n<?  is  defined  as  'the  management  process  a  r 
determining  and  acquiring  the  range  and  quant i tv  of  support 
items  necessary  to  operate  and  maintain  an  end  item  of 
materiel  for  an  initial  period  of  service  i4;4i,"  an v  new 
sVstr.un  'if  even  moderate  cornp  i  P  V  i  t  v  w  i  i  1  soon  he  useless 
unless  the  support  items,  primarily  spa  re  and  repair  par’s 
and  test  equipment,  that  it  needs  are  ava i table.  To  >  iaim 
that  a  new  system  is  finally  operational  then,  it  is 
necessary  to  obtain  not  on  1 v  the  prime  mission  equipment  . 
the  end  item,  bur  also  a  complement  of  the  support  items 


r  ha  t  ir'-'  uprps^.trv  to  on»r<)  r  e  ano  m-i  irif'Un  1  t  . 

in  d-  »rmining  wiirif  ^ppri  fie  ?iir.nnrr  i  t  pms  -inn 
quail'  ■  ins  ,ire  su  f  f  i  c  i  ent  for  a  given  sv«r  em  ,  nm  Air  F<irf,H 
;jsns  provisioning  data  which  ar^  norma  i  1  y  supplied  by  f  he 
prime  contractor.  Each  part  In  a  system  is  described  in 
this  provisioning  data  in  forms  of,  among  of  her  things ,  its 
probable  failure  rate,  the  wav  it  will  be  repaired,  md  i  t  s 
p  i  a  o  o  in  the  svstem’s  hierarchv  of  parts,  also  i  n~  i  uded  in 
t  he  prov i s i on i ng  data  are  any  toois,  rest  equipment,  or 
or  her  sundrv  items  requ i red  to  operate,  service,  or  repair 
t  lie  end  item  (  o  :  o  )  . 

An  Air  Force  technical  staff  reviews  the  data, 
ultimately  recommends  buy  quantities  for  every  item  that 
w i i !  be  required,  and  starts  the  procurement  process  that 
will  eventually  place  each  item,  in  the  quantities  needed . 
t  a  *  he  Air  F  n  r  re  s  1 1  n  p  1  v  s  vs  f  em  <  I  1 1  :  1  ;  n  :  1  i  ,  •"  a  —  “  “>  J  .  A  j  i  this 

must  tie  ac  comp  i  i  shed  be  fore  sue,  ess  t  u  1  fielding  of  f  i-e  new 

s  \  i  t  em  can  occur.  The  process  is  time  consuming  and  must  ho 
srarr  ed  eariy  enough  in  the  acquisition  schedule  of  the  end 
;tom  that  it  can  he  •  ornp  i  e  t  etj  hv  t  fie  time  the  end  item  is 
tie  r  t f  i  > ,  r  i  a  i  .  1  r  must  a  *  t  h**  same  time  he  st  ar*  e<i  i  a  t  e 

o  r  •  ■  O  •  1,  r  [  t  ha  t  trio  end  i  t  em  is  sufl  1  c  i  e  !1 1  1  V  des  i  gtl  s  t  a  h  i  e  , 

\ a T  1 1  r a  1  i v .  ir  the  design  of  the  end  irem  changes,  the 
suonor  t  i  t  o m -  j  t  r<*q'i  i  res  will  change  as  we  j  i  .  when  t  hat 

r i  t  o po  r ; a  I  ter  provisioning  has  r>»> g < m  ,  some  new  ami  different 


i  w i  i  I  havp  r  n  ho  procured  arid  some  i  t  cms  a  i  r*>  v*  v  he- j  »>g 

procured  wi  i  i  have  t  o  he  withdrawn  r  mm  nrocuromenr  . 

Due  large  i  v  to  the  romp  1  ex  i  tv  of  new  air  For -'e  ems 

some  changes  to  the  design  frequent iv  do  nmir  a  r  r  e  r  rhp 
provisioning  process  has  begun .  Design  change  riot  ires 
y DC N s )  are  used  to  not i f v  the  government  of  changes  r  haT 
have  occurred  to  provisioning  data  which  add  to,  de  jet*-, 
supersede  or  modi f v  items  that  nave  already  been  suhmi t  r  ed 
bv  the  contractor  (5:13),  Large  numbers  of  changes  ape 
cost ly  both  in  the  expense  of  their  preparation  by  t  he 
contractor  and  in  the  expense  of  their  subsequent  process  in 
by  government  personnel.  More  importantly,  these  changes 
interfere  with  and  delay  the  acquisition  process,  adversely 
affecting  initial  and  subsequent  operational  o a pa hi  1  it  y  of 
1  he  end  item  by  reducing  the  support  capability  ava i  iabie 
fcr  i  t  S  effective  use. 

Problem  o  t  a  t  ement 

Large  numbers  of  DC  N  s  do  occur  during  the  deve 1 opmen  t 
and  acquisition  of  sir  Force  weapon  systems.  Provisioning 
•>r  i  i  i  r  v  on  F»<”  \  s  is  nor  spec  i  i  i  c  a  bo  ut  processing  procedures 
and  govern i ng  regulations  are  not  always  in  agreement . 

Whi  i e  the  fact  that  every  weapon  system  is  dif repent  ho t  h  i 
ferms  of  equipment  type  and  provisioning  strategy  suggests 
t  ha  *  t  hf>  numbers  and  tvpes  of  pr\s  will  be  program  speo  j  i  j. 
even  the  average  quantities  and  tvpes  of  DC  Ns  being 


submit*-. ed  are  unknown. 


This  study  describes  DCNs  and  current  DCN  procp^sin?  in 
the  Air  Force  to  determine  whether  improvements  ere  possible 
and  suggests  alternative  processes. 

Investigative  Questions 

To  accomplish  the  objectives  of  this  research;  the 
following  detailed  questions  were  asked: 

1 .  What  is  the  DCN  process? 

2.  Who  are  the  players  in  the  process  and  what  are 
their  individual  requirements  for  the  data? 

3.  How  many  and  what  types  of  DCNs  are  processed 
relative  to  the  total  number  of  line  items? 

4.  How  much  \eriation  in  the  types  and  numbers  of  DCNs 
exists  among  different  contracts? 

S c o p e  of  the  Research 

The  bulk  of  Air  Force  weapon  system  management , 
including  provisioning,  is  divided  between  rive 
geographically  separate  Air  Logistics  Centers  (ALCs).  The 
responsibility  for  Air  Force  provisioning  policy  resides  at 
the  Air  Force  Logistirs  Command  ( A F 1 C )  headquarters  at 
W r i gh t — Pa t t e r s on  Air  Force  Base,  Ohio,  but  the  specific 
processes  by  which  that  policy  is  implemented  may  vary 
dramatically  between  the  five  ALCs. 

DCN  process  research  was  concentrated  on  provisioning 
at  Warner  Robins  Air  Logistics  Center  ( W R  —  A L C )  ,  Georgia. 

The  other  four  centers  were  solicited  for  incut  on  their 


orocedures  with  regard  fn  DCNs  and  these  were  a  iso 
incorporated.  Some  support  items  than  are  not  specific  to  a 
given  WR-ALC  program  are  not  managed  there,  and  part  of 
their  processing  occurs  at  other  locations.  The  off— oase 
processing  of  these  items  is  not  a  subject  of  this  research. 

DCN  data  examined  were  limited  to  data  from  programs 
that  are  assigned  to  WR-ALC.  Data  were  drawn  f^om 
provisioning  contracts  in  the  following  three  groupings:  1) 

an  aggregate  of  all  contracts  within  the  WR-ALC  provisioning 
database,  2)  a  smaii  group  of  twelve  completed  contracts, 
and  3)  contracts  associated  with  the  Low  Altitude  Navigation 
and  Targeting  Infrared  System  for  Night  (LANTIRN)  program. 

Justification 

General  Alfred  G.  Hansen,  the  AFLC  commander,  has 
emphasized  the  importance  of  quality  in  Logistics  processes. 
Process  Action  Teams  (PAT)  have  been  organized  throughout 
the  command  to  improve  process  quality.  The  PAT  is  made  up 
of  personnel  who  are  involved  in  different  aspects  of  a 
given  process.  AFLC,  through  the  Provisioning  Policy 
branch  of  the  Directorate  of  Materiel  Policv,  requested  that 
a  study  of  DC N s  be  done  in  coordination  with  the  efforts  of 
two  DCN  PATs  currently  operating  within  AFLC.  The  results 
of  this  study  together  with  the  findings  of  the  two  PATs 
will  be  used  to  evaluate  current  provisioning  policy 
concerning  DCNs  and  will  serve  as  a  reference  for  the 


ppwri^  of  the  DC\  portion  of  file  Air  Force  Prov  is  i  on  i  ng 
policies  and  Procedures  reffii  1  at  i  on  ,  AFLCp  AGO  —  Q.  Better 
guidance  in  AFLCR  800—9  is  hoped  to  lead  to  reduced  costs 
and  increased  readiness  through  more  timely  and  efficient 
delivery  of  initial  support. 

As  sumpt ions 

This  research  is  based  on  the  following  assumptions  and 
1 imi t  at i ons  : 

11  Completed  programs  in  the  aggregate  are  not 
s i gn i f i cant  ly  different  than  current  and  future  programs  in 
the  aggregate,  in  terms  of  numbers  and  types  of  DCNs 
relative  to  each  other  and  to  the  total  number  of  line 
items. 

2)  Fxisfing  queries  of  the  AFLC  Management  and  Control 
of  Provisioning  System  DSD  GO 6 4  are  valid  < i 1 : 1 8 ;  15:i-6). 

The  GO 8 4  is  an  interactive  database  that  serves  as  an 
interface  to  the  D220,  the  Air  Force  provisioning  system. 

1)  Data  are  not  segregated  historically.  DCN'  policy 
may  vary  even  over  the  life  of  a  single  program,  certainly 
over  the  aggregate  of  all  programs  to  date.  Therefore,  data 
concerning  a  program  represent  the  sum  total  of  everything 
that  has  been  submitted  to  date  and  do  not  necessarilv 


reflect  the  latest  provisioning  policy. 


Review  of  the  Literature 


I  I  . 


I nt redact  ion 

Virtually  everyone  involved  with  DC.\'s,  at  the  plans  and 
policy  level  as  weil  as  the  working  level,  agrees  that  DCN's 
are  a  serious  problem  in  Air  Force  acquisitions.  According 
to  the  Information  Resources  Management  Branch  at  Ogden  ALC , 
'The  processing  of  DCN's  is  probably  the  most  difficult  thin? 
to  do  in  the  provisioning  process,  to  sav  the  least  (  i  6 : 1 ) ■  " 

In  the  fall  of  1987  the  approximate  number  of  DCN's 
being  processed  at  one  time  at  each  of  the  five  ALCs  ranged 
from  4,500  to  36,000  (13:2).  The  B— IB  Strategic  Bomber 
system  probably  set  a  record  for  a  single  program:  over 
187,000  DCNs  submitted  as  of  January  1988.  A  point  of 
interest  is  that  the  United  States  General  Accounting  Office 
(GAO)  mistakenly  reported  that  187,955  design  changes  had 
been  submitted  at:  that  time;  they  were  actually  design 
change  notices  (12:30).  This  research  wiil  show  that  design 
changes  and  DCNs  are  two  different  things,  and  two  DCN's  are 
often  submitted  for  only  one  design  change.  The  consolation 
is  small;  the  Air  Force  still  processes  them  all.  At  the 
ciose  of  this  research  the  number  of  DCNs  nn  the  B-1B  had 
risen  tn  over  228, nnn  and  they  are  still  coming  in. 

A  function  of  the  Headquarters;  AFLC  Provisioning  Policy 
Branch  is  to  improve  the  provisioning  processes,  and  the  DC N 
problem  is  no  exception.  Their  focus  has  been  to  emphasize 


the  segregation  of  DC  Ns  into  two  car  egor  i  es  .  engineering— 
type  change  notices,  and  adm  i  n  i  s  f  rat  i  ve-  type  change  not  ices  . 
This  policy  has  been  ili  received  in  the  field  due  to  a  lack 
of  consensus  that  administrative-type  changes  occur  in 
sufficient  quantities  to  be  worth  tne  trouble,  and  a  lack  of 
understanding  of  what  is  to  be  gained  if  they  are.  The 
headquarters  position  is  that  administrative-type  changes 
probably  occur  in  significant  numbers,  are  less  important  to 
provisioning  than  engineering-type  changes,  and  "’ey  be 
handled  separately,  allowing  the  provisioning  office  to 
"make  or  not  make  the  changes  they  deem  appropriate  (1:1).  ' 
Before  this  issue  can  be  further  addressed,  two  questions 
must  be  answered:  what  exactly  is  a  D CM,  and  are 
admi n i s t ra t i ve-tvpe  changes  really  different? 

To  address  the  first  cruestion,  this  review  follows  the 
description  of  DC Ns  through  the  hierarchy  of  governing 
regulations  from  Military  Standard  through  AFLC  regulation, 
to  AFLC  Manual,  and  finally  to  the  Air  Force  Addendum  to  the 
Military  Standard.  The  emphasis  of  this  drawn-out  review  of 
the  definition  of  a  DCN  is  to  establish  the  difference 
between  a  notice  due  +n  an  engineering  change  and  a  notice 
due  to  an  administrative  change  and  to  explain  why  noth  are 
known  as  DC Ns ,  thereby  answering  the  second  question. 
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PCX  Description 


MI  L-5TD-1  56  IB  .  The  bn  if  orm  Provisioning  Procedures 
Standard  for  the  Department  of  Defense,  MIL-STD- 1 56 IB , 
provides  the  following  definition  for  DCN's:  'A  design 

change  notice  is  used  to  identify  changes  to  Provisioning 
Technical  Documentation  ( PTD )  which  add  to,  delete, 
supersede,  or  modifv  items  previously  listed  which  are 
approved  for  incorporation  into  the  end  item. ”  It  gees  on 
to  say  that  "The  contractor  shali  notify  the  provisioning 
activity  of  all  changes  whether  of  a  production  or 
modification  type  which  are  approved  for  incorporation  into 
the  system/eauipment  furnished  under  the  contract  (5:13)," 
The  words  design  change;  add  to,  delete,  supersede,  or 
modify  items;  and  approved  for  incorporation  into 
system/equipment  are  important.  It  is  items  that  are  being 
changed  and  not  just  data  under  this  definition,  and  the 
items  change  because  of  a  government  approved  change  to  the 
design  of  the  system/equipment.  This  translates  into  a 
simplified  working  definition:  DCN's  identify  changes  to  PTD 
resulting  from  approved  changes  to  the  design  of  the 
system/equ iprnent .  Corrections  to  data  errors,  about  items 
that  have  net  changed,  having  nothing  to  do  with  a  change  o 
the  design,  clearly  do  not  fit,  and  are  not  DCN's  under  this 
definition.  Indeed,  a  contractor  requirement  to  notify  the 
provisioning  activity  of  error  corrections  is  not  addressed 


at  all  bv  this  standard. 


MI L-STD- 1 388-2A ■  M I L-STD- 1 56 1 B  is  written  r o  be 

compatible  with  MI L-STD- 1 388-2A  and  is  to  be  used  in 
conjunction  with  that  document  (o:iii,l).  MIL-STD-1 388-2A , 
POD  Requirements  for  a  Logistic  Support  Analysis  Record , 
does  not  specifically  define  DCNs  so  the  MI L-STD- 1 66 IB 
definition  applies.  MIL-STD-1 388-2A  does  acknowledge  that 
errors  and  other  types  of  changes  will  occur  to  provisioning 
data,  and  distinguishes  them  from  DCNs.  Under  MI L-STD- 1 388- 
2A,  provisioning  data  is  reported  in  the  LSA-036  Report.  In 
Appendix  B,  40.33.4,  titled  "LSA-036  Update  and  Design 
Change  Notices,"  five  types  of  updates  are  identified  which 
can  result  when  data  is  added,  changed,  or  deleted  affecting 
provisioning  data  previously  delivered.  The  five  updates 
are  1)  Standard  Data  Update,  2)  Quantity  Data  Update,  3)  Key- 
Data  Update,  4)  Associated  Data  Update,  and  5)  DCNs 
(3:236,237).  The  explanations  for  each  of  the  five  types  of 
update  are  complicated,  appear  to  be  incomplete,  and  are 
certainly  difficult  to  understand.  They  focus  mainly  on 
which  data  fields  will  need  to  be  changed  for  each  type  of 
update.  Not  specified  is  the  reason  why  each  of  the  five 
types  of  updates  might  have  occurred,  only  that  changes  had 
occurred.  M I L— STD— 1 388— 2 A  goes  on  to  state  that  "BCN 
information  is  not  distinguished  from  other  updated  data  for 
a  particular  LSA-036  update  (3:237)."  So  although  at  least 
some  updates  are  not  DCNs,  it  is  impossible  to  tell  whether 
a  change  was  or  was  not  a  DCN  once  + he  update  is  made. 


Pecail  the  ur  N  working  definition  based  on  the 


definition  in  MI  L-STD-1  r>6  IB :  DCNs  identify  changes  to  PTD 
resulting  from  approved  changes  to  the  design  of  the 
system /'equipment  .  Some  or  all  of  the  othQr  four  updates 
might  also  be  the  result  of  approved  changes  to  the  design. 
For  example,  a  quantity  change  due  to  an  approved  design 
change  seems  to  fit  equally  well  into  either  the  quantity 
data  update  or  the  DCN  category.  A  quant  it v  change  to 
coroert  an  error,  however,  would  fit  the  quantity  data 
update  category  but  not  the  DCN  categorv. 

Also  provided  by  MI L-STD-1 388-2A  are  the  Type  of  Change 
Codes  ( TOCC )  used  to  segregate  tvpes  of  DCNs.  The  codes  are 
listed  in  Tabl e  1 . 


Table  1.  Type  of  Change  Codes 


i  i.n.  i. 


Explanation 


M 


D 


Modified  item. 
Deleted  it em . 


T 

0  (or  A ) 


L 


< , 


Typographical  error. 
Quantity  adjustment. 
Limited  part  application. 
Deletion  of  data  element. 


Since  the  Air  Force  Provisioning  System,  D220,  was 
designer!  around  the  old  and  now  obsolete  M I L-STD- l  o  o  2  A  , 


changes  are  made  by  D220  to 


the  original 


L S A  —  0  36  codes. 


MI L-STD- 1 5 5 2 A  and  consequently  D220  does  nor  recognize  a  G, 
deletion  of  data  element  (6 ’6).  Air  Force  regulations 
reviewed  do  not  explain  what  happens  to  a  G  TQCC  when  it 
enters  the  D220,  It  is  assumed  that  a  G  TOCC  is  conv>i rod 
to  M  for  modified  item.  In  addition,  D220  recognizes  both  a 
quantity  increase  and  decrease  so  the  0  becomes  an  A  if  the 
quantity  actually  increased  and  remains  the  same  if  the 
quantity  decreased  (7:6—2), 

AFLCR  8  00-9.  The  Air  Force  Provi  si on_i ng  Po  1  i  cies  and 
Procedures ,  AFLCR  800-9,  is  an  Air  Force  regulation  while 
the  two  military  standards  are  DOD  level.  AFLCR  800-9 
defines  DCNs  this  way:  "The  DCN  is  the  type  of  PTD  used  by 

the  contractor  to  notify  .  .  ,  the  provisioning  activity  of 

all  engineering  changes  .  .  .  which  are  approved  for 

incorporation  into  the  end  item  on  contract  and  which 
modify,  add  to,  delete  or  supersede  parts  in  the  end  item  or 
its  supporting  equipment  (8:57)."  This  definition  is 
specific  in  stating  that  DCNs  result  from  engineering 
changes  that  are  approved.  This  detail,  that  approved 
changes  are  approved  engineering  changes,  should  prove  to  be 
an  important  and  useful  point  since  engineering  changes 
proposals  (ECP)  are  what  are  approved  by  the  government  to 
effect  changes  to  the  design,  and  they  are  well  documented 
and  carefully  numbered  (2:38-5  3).  What  AFLCR  800-9  dop<;  not 
do  is  identify  or  address  changes  to  provisioning  data  due 
to  other  than  approved  engineering  changes. 


■Jfp 


A  FLO]  67-1"' .  Anv  updates  to  the  ISA— 0"tn 
Input  directly  into  the  AFLC  Provisioning  System,  D220,  as 
type  of  Provisioning  Technical  Documentation  (PTD)  "D"  for 
Design  Change  Notice.  AFLCM  65-33,  the  AFLC  Provisioning 
System  (D220)  Users  Manual,  does  recognize  engineering 
changes  and  other  than  engineering  changes .  The  former  are 
identified  as  '’Changes  Resulting  From  DC  Ns"  and  the  latter 
are  identified  as  "Changes  Not  Resulting  From  DCNs."  The 
shortened  titles  are  DCNs  and  Change  Act  ions  (CA> .  Except 
for  the  different  headings,  the  D220  output  products  are  the 
same  for  ..It her  CAs  or  DCNs  (7:6-11,  6-2).  The  differently 
titled  products  are  processed  through  D220  in  exactly  the 
same  way  with  the  same  processing  times  (7:5-21).  Because 
both  are  submitted  as  "Design  Change  Notice,"  type  PTD  "D," 
and  because  no  significant  difference  in  processing  is 
identified,  both  CAs  and  DCNs  are  widely  Known  as  DCNs. 

According  to  AFLCM  65-33,  D220  recognizes  DCNs  by  an 
entry  in  the  "engineering  change  authority"  block  on  the 
D220  input  tape.  CAs,  by  default,  are  recognized  by  the 
iack  of  an  entry  in  the  engineering  change  authority  block. 
It  is  this  difference  that  the  D2 2 0  svstem  uses  to  separate 
and  then  title  its  output  products  7:6-11).  Whether  the 
change  authority  field  is  an  appropriate  discriminator  or 
not,  it  is  the  discriminator  used  by  the  D?20. 

More  details  are  given  in  AFLCM  65-A3  on  differences 
between  CAs  and  DCNs.  These  uetails  appear  to  confuse  the 


I  t 


issue,  since  the  actual  segregation  is  based  on  the  change 
authority  fie  id.  finder  the  heading  Type  PTD"  and 
subheading  "D  Design  Change  Notices"  is  the  statement  that, 
"an  item  received  with  a  type  PTD  of  ’DT  and  a  TOCC  'D' 
delete,  ’  Q  *  quantity  decrease,  :A’  quantity  increase,  or  L' 
limited,  accompanied  by  an  engineering  change  authority 
number  snail  be  output  as  a  Design  Change  Notice' . "  Of 
course  the  same  is  also  true  of  the  other  TOCCs  "M"  and 
"T."  Also  stated  is  that  "an  item  received  with  a  type  PTD 
of  'D'  and  a  TOCC  of  ’T’  t  ypngrap'n  i  ca  1  error  shall  be  output 
as  a  'Notice  of  Change  Action'  (7:6-2)."  This  is  true, 
however,  only  if  the  Change  Authority  Block  is  blank  in 
which  case  any  other  TOCC  will  produce  a  CA  as  well.  A  TOCC 
of  M  is  no+  mentioned.  Still  e I sewhere  in  the  same  chapter 
is  the  statement  that  CAs  are  indicated  when  the  Change 
Authority  field  is  not  filled  and  portray  quantity  changes 
or  corrections  of  typographical  errors.  These  conditions 
correspond  to  TOCC  Q  or  A,  and  T;  left  out  are  D,  M  and  L, 
which  also  result  in  CAs  if  the  Change  Authority  field  is 
not  filled.  In  the  same  paragraph  it  goes  nn  to  say  that 
data  elements  that  have  been  changed  by  the  contractor 
independently  will  have  a  TOCC  of  T  (7:6-12,  6-13).  This  is 

not  necessarily  true.  TOCCs  are  assigned  automatically  by 
the  field  or  fields  that  changed,  not  by  the  reason  the 
field  changed  or  on  whose  authority  it  was  changed  (3:180). 
It  is  unclear,  how  a  TOCC  of  T  could  ever  be  automatically 
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a <5  s  i  g- ne <i  .  A  ('h^nsp  n  f  o u a n t  i  t  v  f  r^in  on#1  t  n  r  wo  cou  i  d  be  on#* 
to  typograph i ca i  error,  design  ('ivinge,  or  s  imp  i  p  misMkp. 

Ai_r  Force  Addendum,  The  MTL-STDs-1  3A6-2A _ and  1  5  «S  1 B 

Provisioning  Requirements  Statement  Ai r  Force  Ad dend urn,  is 
uncomplicated.  I'nder  t  he  heading  Design  and  Administrative 
change  Notices,"  are  r  he  foi i owing  "Categories:  I)  Design 

Changes  which  result  from  an  approved  Engineering  Change 
Proposal  iECP),  which  require  an  entry  in  tfie  Change 
Authority  block,  and  2)  " Non- EC P  changes  resulting  from 

omission  or  correction  of  data  submitted  by  the  contractor. 
These  changes  are  considered  Administrative  Change  Notices 
fACNs).  The  Change  Authority  block  .  ,  .will  be  blank 

i N : 2 ) . "  AC N s  from  the  Air  Force  Addendum,  corresnond 
direct i v  to  CAs  from  AFLCM  AS-ll;  the  Change  Author i t  v  block 
is  blank.  The  Air  Force  Addendum  goes  on  to  sav  that  r  wn 
different  methods  for  submittal  ar<*  a  i  i  owed  for  A«  '\  s  .  The  v 
may  he  submitted  just  as  any  other  update,  with  the  evtra 
requirement  that  the  reason  for  the  change  he  provided  in  a 
remarks  block;  and,  if  authorized  by  the  ALC  provisioning 
-■ection,  t  tie  v  mav  be  submitted  bv  message  describing  t  he 
changes  to  be  made.  How  the  information  in  the  message  i^ 
to  be  processed  is  not  addressed.  Headquarters  VFLC 
Provisioning  Policy  does  state  that,  for  AC \: s  submitted  bv 
message,  the  provisioning  office  is  "responsible  to  make  or 
not  make  the  changes  they  deem  appropriate,  (  1  :  1  >  . 


Summary 

What  is  rnmmnniv  rpfprrpn  to  as  DC  N  s  <i('t  ih  [  i  v  i  rie  iudes 
two  different  kinds  of  c  han^*?  s  ,  DC  \  s  a  nd  At  \  s  .  D<  \  s  rpsn  i  t 
from  a  change  to  the  design  and  ACNs,  sometimes  referred  to 
as  CAs ,  result  from  something  other  than  a  change  to  the 
d  e  s i gn .  snecificailv  omissions  or  corrections.  A i  i  of  r  he 
re gu 1  a ♦  ions  reviewed  showed  that  DC  \  s  were  differenr  t ha n 
ACN's  ,  although  %1 1  L- ATD-  1  on  1  B  failed  to  recognize  that  AC\s 
exist  .  F'ne  change  ant  her  i  t  y  block  was  identified  in  A  F  i  <  '1 
h-'i-ti  and  the  air  Force  Addendum  as  being  the  sole 
discriminator  between  AC N s  and  DC Ns ,  although  M I L-oTD- 1 Aflfl- 
v A  st  a  ted  that  pc Ns  cou 1 d  not  he  dist inguished  f  rom  other 
tvpes  of  updates  once  the  updates  were  made.  In  no  case 
were  ac\'s  and  DCN's  referred  to  as  subseTs  of  a  iarger 
- t  egor  v  ,  DC  Ns  ,  a1  though  that  is  a  common  perception  and 
both  are  submitted  to  the  air  Force  intermingled  on  a  type 
of  Pin  titled  ‘Design  Change  Notice.' 


III.  be  I  nniio  i  ncrv 


I n t redact  ion 

This  chapter  describes  the  methodology  used  tn  address 
the  research  problem  identified  in  Chapter  I.  The  research 
effort  was  conducted  in  two  phases:  the  process  phase  and 

the  data  phase. 

The  process  phase  was  an  investigation  into  the  pd\ 
process  fiow.  Three  sources  of  information  were  used,  for 
the  process  phase:  1)  the  governing  regulations, 

part icu lar ly  AFLCB  65-33 ,  2)  on  site  interviews  of 
participants  in  the  process  at  WP-ALC,  and  3)  information 
prepared  by  the  other  four  Aids  about  their  local  pro.  esses 
The  combination  of  hands-on  evaluation  of  r  he  process  a-  on 
<'enter  and  information  about  t  he  local  processes  sunn  i  i  .*.*  b 
the  other  ren  t  ers  nrov  i  ded  t'ne  researcher  a  ■  •  <  *  -  r  — . »  •  -  .>  •  r  ; 
method  to  access  expertise  rl  t  ail  five  aids. 

The  data  phase  was  a  review  of  the  data  for 
provisioning  contracts  at  W  R — A  L  d  to  describe  the  quant  i  *  i e  s 
and  t  vpes  of  pc \ s  found.  Three  t  vnes  i  >  t  c o  n  r  r a  1  t  gr  u '  - ■  • 
were  cove  red  :  1)  the  entire  da  t  abase  at  wff  —  aid,  .  •  •  w**  -.  \  *• 

s  e  i  e  r  t  e  d  complete  d  contracts  ,  and  3  )  a  S  pec  i  r  i  pr  ■  g  r  .  i  •’!  •  i  v 


itself,  i.  a  N  1  I  P  N 


The  Process  Phase 

Interviews  at  WR-ALC  and  inputs  from  the  other  centers 
were  used  to  develop  an  accurate  although  simplified  block 
diagram  of  the  DCN  process.  The  block  diagram  is  divided 
into  five  different  stages.  The  stages  of  the  DCN  process 
are  defined  by  the  flow  of  the  DCN  into  and  out  of  the  Air 
Force  Provisioning  System,  the  D220. 

I nterv i ews .  Participants  in  the  processing  of  DCNs  at 
WR-ALC  were  interviewed.  Participation  was  voluntary  and 
confidential.  The  selection  of  interview  subjects  at  each 
stage  of  the  process  was  based  on  the  recommendations  of 
supervisors  and  peers,  and  the  availability  of  those 
recommended  and  their  agreement  to  be  interviewed.  The 
interview  consisted  of  the  following  questions: 

1.  Which  of  the  data  fields  of  a  DCN  do  you  need  to  do 
vour  job? 

2.  what  do  you  use  them  for? 

?.  Do  you  handle  some  DCNs  differently  than  others? 

4.  If  so,  what  are  those  differences? 

a.  Where  do  the  forms  come  to  you  from? 

rS  ,  Wherp  do  you  send  f’nem  and  under  what  conditions? 

7.  i'nder  what  conditions,  if  anv,  is  the  D<"\  not 
necessarv  for  you  to  do  vour  job? 

A.  Cnder  what  conditions,  if  any,  would  yon  not  send  a 
DCN  forward? 

Other  ALC  Inputs.  The  Headquarters  AFLC  Provisioning 
Branch  PAT  on  DCNs  requested  and  received  a  description  of 


the  DCN  process  fiow  from  the  four  ALCs  other  then  WR-ALC . 
The  responses  verier!  bv  level  of  detail  but  they  were  all 
very  similar  to  the  researcher's  finding's  at  WR-ALC  . 

The  Data  Phase 

DCNs  were  categorized  three  different  wavs:  1)  they 

were  identified  by  one  of  seven  TOCCs,  2j  they  were 
identified  as  being  either  ACNs  or  DCNs,  and  A)  they  were 
identified  as  referring  either  to  procurable  or  non- 
procurable  items.  The  DCNs  were  analyzed  by  category  within 
the  context  of  the  contract  grouping  to  which  they  belonged. 
Three  tvpes  of  contract  groupings  were  covered:  1)  the 

entire  database  at  WR-ALC,  2)  twelve  selected  completed 
contrac+s,  and  3)  a  specific  program  by  itself,  LANTIRN. 

The  G064 .  The  G064  system  at  WR-ALC  was  queried  for 
its  content  of  selected  information  in  an  attempt  to 
identify  significant  similarities  and  differences  that  might 
occur  among  the  contract  groupings.  The  G064  system  ie  an 
on-line,  interactive  database  that  serves  as  an  interface  to 
the  more  cumbersome  and  dated  flat  fiie  provisioning 
database,  the  D220  system.  The  G064  houses  ai 1  the  same 
data  as  the  D220  and  the  user  appears  to  be  accessing  the 
D220  directly.  What  actually  happens  is  the  G0f>4  files  are 
manipulated  and  then  are  periodically  sent  to  the  D220  as  an 
update.  Afterwards,  the  updated  D220  sends  the  new  files 
bank  to  G 0 6 4  for  further  editing  (11:1—4).  The  G 0 A 4 
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provides  a  fairly  convenient,  user-friendly  means  of 
accessing  D220  data.  Several  G0r>4  queries  that  directly  or 
indirectly  apply  to  DCNs  already  exist  within  the  system  and 
were  suitable  for  this  research  (15:1-6). 

The  Population.  There  were  500  provisioning  contracts 
in  the  G064  system  in  May  of  1989  when  the  data  were 
gathered.  The  entire  population  of  all  DCNs  for  ail  500 
contracts,  representing  almost  ten  years  of  provisioning, 
were  queried  to  get  an  aggregate  description  of  DCNs  at  Wp- 
ALC  . 

Next,  a  selection  of  completed  contracts  was  queried. 
Completed  programs  are  significant  because  of  the  likelihood 
that  the  numbers  and  types  of  DCNs  evolve  as  a  system  is 
produced  and  eventually  fielded.  Analyzing  a  combination  of 
systems  in  different  stages  of  production  and  fielding  could 
result  in  a  distorted  picture  of  the  types  and  numbers  of 
DCNs  over  a  program’s  life.  For  this  research,  completed 
contracts  were  defined  as  those  contracts  with  little  or  no 
activity  in  the  last  two  years.  A  letter  requesting  a 
listing  of  contracts  that  fit  the  definition  for  completed 
programs  was  sent  to  the  provisioning  office  at  WR-ALC .  The 
expression  'little  or  no”  was  deliberately  inexplicit  to 
allow  the  provisioners  to  use  their  own  judgement  as  to 
whether  significant  numbers  of  changes  had  occurred.  The 
letter  was  circulated  among  the  provisioners  for  input. 

Only  twelve  programs  finally  were  selected  as  oompleted  and 


they  were  investigated  and  combined  to  develop  a  composite 
of  the  completed  contracts. 

Finally  a  single  program,  LANTIRN,  was  investigated. 
LANTIRN  was  selected  because  it  was  a  large  and  currently 
active  system  managed  at  WR-ALC  that  had  experienced 
significant  design  changes. 

Quantities  of  DCNs  Versus  Original  Data.  The  three 
contract  groupings  were  checked  for  the  number  of  DCNs  that 
were  submitted  for  every  100  original  items  submitted. 

Types  of  DCNs. 

By  TOCC ■  A  key  element  in  determining  DCN  type  i 
the  type  of  change  code  (TOCC).  The  TOCC  is  automatically 
generated  based  on  the  actual  type  of  change  that  was  made. 
Relative  frequencies  of  the  seven  TOCCs  were  gathered  for 
the  three  kinds  of  contract  groupings. 

The  six  type  of  change  codes  found  on  DCNs  follow: 

M  Modified  item. 

D  Deleted  item. 

T  Typographical  error. 

A  Quantity  increase. 

Q  Quantity  decrease. 

L  Limited  part  application. 

Blank  Additional  items. 

AC Ns  Versus  DCNs.  Only  LANTIRN  was  evaluated  for 
whether  the  changes  were  actually  ACNs  or  DCNs.  This 
required  a  closer  look  including  a  review  of  the  change 


authority  block  which  is  nor  accessed  bv  the  quantity  and 
type  query.  Ten  data  fields,  including  Change  Authority, 
were  printed  out  for  every  DCN  submitted  on  the  LANTIRN 
program  to  date.  Nearly  8,000  DCNs  had  been  submitted.  The 
Change  Authority  code  identifies  the  authority  for  a  change 
and  is  used  to  differentiate  between  administrative  and 
engineering  changes  (3:180,194,458,554;  9:1).  If  there  was 
an  entry  in  the  Change  Authority  field,  the  change  was 
counted  as  a  DCN;  if  the  Change  Authority  field  was  blank  it 
was  counted  as  an  ACN.  The  totals  were  used  to  develop  the 
percentages  of  DCNs  and  ACNs, 

Since  the  difference  between  ACNs  and  DCNs  depended  on 
only  one  field  of  information,  the  Change  Authority  field, 
that  field  was  the  subject  of  further  scrutiny.  Some  of  the 
filled  Change  Authority  fields  were  determined  to  be  not 
valid.  They  had  entries  such  as  "Adminchg.  ''  A  second  set 
of  percentages  was  developed  that  included  invalid  Change 
Authority  fields  that  indicated  an  administrative  change  as 
ACN s  . 

Procurable  Versus  Non-procurab 1 e ■  Items  that  were 

originally  selected  for  procurement  are  called  procurable 
items.  DCNs  submitted  against  procurable  items  are  defined 
for  this  research  as  procurable  DCNs.  Items  that  wer? 
originally  not  selected  for  procurement  are  non-pronj rab i e 


i  t  ome  . 


DCNs  submit  tod  against  non-nrocu rab 1 e  it^ms  am 


defined  for  this  research  as  non-procurab 1 e  DCNs. 


LAN l IRN 


was  reviewed  for  procurable  versus  non-procurab 1 e  items. 

Ana lvs i s 

A  process  flow  chart  was  created  based  on  the 
information  gathered  from  the  AFLCM  65-33,  the  interviews  at 
WR-ALC ,  and  the  inputs  from  the  other  four  ALCs.  The  flow 
was  then  examined  for  any  obvious  redundancies  or 
bo  1 1 1 ene  c  k  s . 

The  data  were  analyzed  by  category  to  determine  the 
types  and  relative  quantities  of  DCNs  being  submitted. 
Knowledge  about  the  types  and  quantities  of  DCNs  was  used  to 
identify  specific  types  of  DCNs  being  submitted  that  were  of 
sufficient  magnitude  to  warrant  further  investigation  or 


IV  .  Finding's  and  Analvs _i s 


Introduct ion 

This  chapter  consists  of  the  results  obtained  from  the 
two  phases  of  research,  the  process  phase  and  the  data 
phase,  as  described  in  Chapter  III. 

The  Process  Phase 

The  particulars  of  DCN  processing  are  largely  left  to 
the  discretion  of  the  individual  ALCs.  The  Air  Force 
provisioning  policies  and  procedures  manual,  AFLCR  800-9, 
states  that  "DCN  processing  will  be  similar  to  LLIL  [Long 
Lead  Items  List]  processing  (8:57)."  Still,  it  follows  that 
all  the  centers  will  follow  very  similar  processes  because 
there  is  more  specific  guidance  on  LLILs,  and  because  ail 
f'pnrers  are  using  the  samp  computerized  provisioning  system. 

A  review  of  applicable  regulations,  particularly  AFLCM 
65-33,  interviews  of  DCN  process  participants  at  WR-ALC ,  and 
inputs  requested  from  the  four  other  centers  describing 
their  local  processing  were  used  to  develop  the  DCN  process 
flow  chart  in  Figure  1.  The  chart  and  associated  process 
fiow  are  intended  to  represent  a  generic  case  that  is  the 
typical  or  most  common  case  AFLC  wide.  Variations  for 
specific  requirements  of  any  given  program  or  center  may  and 
dr,  occur. 
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Figure  1.  OCN  Process  Flow 


The  stages  of  the  DCN  process  are  defined  for  this 
document  by  the  flow  of  the  DCN  into  and  out  of  the  D220 
system.  The  number'  of  days  identified  with  the  stages 
represents  the  internal  suspenses  assigned  by  the  D220 
system .  1 1  i s  pos s ible  to  change  the  D220  internal 

suspenses  for  any  given  program  when  it  is  deemed 
appropriate  to  do  so  (9:5-22).  The  primary  actions  taken  at 
each  stage,  and  the  process  flow  from  stage  to  stage,  are 
described  below.  Notice  in  Figure  L  that  the  provisioning 
office  handles  the  DCN  six  times.  The  major  emphasis  of  the 
provisioning  function  is  coordination,  data  input,  and  data 
integrity.  The  provisioning  office  is  responsible  for 
keeping  track  of  the  DCN  and  ensuring  that  it  is  processed 
in  a  timely  manner.  To  a  limited  extent  they  are  also 
responsible  for  ensuring  that  the  other  stages  perform  their 
functions  correctly. 

Stage  1 .  The  first  stage  includes  contractor  submittal 
and  initial  actions  by  the  ALC  provisioning  office.  The 
contractor  submits  the  DCN  package  of  magnetic  tape  and 
Supplementary  Provisioning  Technical  Data  (SPTD)  or 
drawings.  The  number  of  DCNs  submitted  at  one  time  varies 
depending  on  program  size,  magnitude  of  engineering  changes, 
and  government  direction.  The  provisioning  office  inspects 
the  package  and  prepares  control  documentation  for  the 
purpose  of  tracking  the  DCN  to  comolefion.  The  tape  is  then 
input  to  the  D220  system.  Subsequent  to  this  initial  D220 


input,  aii  D220  inputs  are  made  manually  through  the  G064 
k evhoard . 

D220  automatically  interface?  with  a  Defense  Logistics 
Support  Center  (DLSC)  computer  to  screen  and  update  the 
DCNs.  The  screen  identifies  stock  numbers  that  have  already 
been  assigned  for  any  items  that  are  listed  without  stock 
numbers.  For  example,  a  DCN  might  be  adding  a  part  which, 
unknown  to  the  contractor,  is  already  in  the  Air  Force 
inventory;  this  would  greatly  simplify  the  support  of  that 
part  . 

St  age  2 .  Next,  D220  outputs  the  DCNs  back  to  the 
provisioning  office  in  the  form  of  a  Technical  Review 
Document.  This  document  is  then  forwarded  with  the  SPTD  to 
the  equipment  specialist  (ES)  for  technical  input. 

The  ES  reviews  the  DCN  to  evaluate  the  technical  data 
fields,  particularly  the  failure  and  maintenance  factor 
codes,  to  determine  whether  they  are  correct.  For  example, 
if  the  data  indicate  that  a  circuit  card  can  be  repaired  in 
the  field,  it  is  the  ES  who  approves  that,  yes,  this  item 
should  be  field  repairable.  But,  if  an  extremely  sensitive 
integrated  circuit  has  been  added  to  the  card,  that  rard  may 
no  longer  be  reparable  outside  the  factory  or  depot,  and  a 
change  will  have  to  be  made.  Any  changes  to  the  data  fields 
are  made  by  circling  the  faulty  data  and  handscribing  the 
corrections  he  low  it.  An  ES  code  is  then  input  to  identify 
the  individual  equipment  specialist  who  performed  the 
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review.  t  hen  the  tS  returns  the  DCN  to  t  he  prn  v  i  s  i  an  i  n  g 
office. 

The  nr"”'  «=  i  oner  checks  the  tprhnicfl  1  review  document 
for  completeness  and  accuracy.  Discrepancies  or 
questionable  entries  are  returned  to  the  equipment 
specialist  for  verification.  Next,  the  provisioner  inputs 
the  equipment  specialist's  updates  to  the  D220  by  wav  of  the 
G064.  The  ES  code  is  the  key  to  the  D220  system  that  the 
technical  review  process  is  complete  and  Stage  3  may  begin. 
Stage  2,  the  technical  review  process,  takes  six  days  or 
less. 

Stage  3,  An  item  manager  (IM)  review  document  is 
output  to  the  provisioner  from  D220  once  the  technical 
review  document  updates  are  in.  The  provisioner  then  routes 
this  document  in  one  of  the  following  three  ways:  1)  items 

managed  by  the  Defense  Logistics  Agencv  (OLA)  are  routed  to 
Dl.A  through  the  supply  support  request  (SSR)  system,  2; 
items  managed  by  other  than  DLA  or  Air  Force  are  routed  to 
those  managing  agencies,  and  3)  Air  Force  managed  items  are 
routed  through  either  the  pri me  or  a  lateral  ALC.  The  prime 
ALT  is  the  ALC  assigned  management  responsibility  for  the 
end  item,  and  many  of  the  DCNs  are  for  piece  parts  that  are 
also  managed  by  the  prime  ALC.  When  the  part  is  managed  at 
an  ALT  other  than  the  prime,  that  ALC  is  designated  the 


lateral  A  i  f  . 


f  the  DCs  is  for  an  item  that  is 


r,sp. 

manageo  by  DLA  or  another  service  the  D2  20  initiates  an  ASP 
through  the  D220/D169  interface.  If  the  item  has  already 
been  involved  with  the  D220/D169  interface,  for  example,  an 
SSP  has  gone  out  from  the  original  provisioning  and  now  a 
DCN  has  been  generated  to  make  a  quantity  change,  then  a  DCN 
review  document  is  output  to  the  provisioner.  The  DCN 
review  document  with  appropriate  SPTD  are  sent  to  r'ne  SSP 
unit  for  manual  processing.  Since  the  time  that  DLA  spends 
with  the  document  is  bevond  the  control  of  the  provisioner 
and  D220,  the  DCN  review  document  is  not  suspensed  by  D220 
and  the  D220  update  that  occurs  after  the  SSP  is  complete 
may  occur  at  any  time. 

Other  Agencv.  Items  that  are  not  Air  Force 
or  DLA  managed  are  output  from  D220  as  an  Id  review  document 
+o  the  provisioning  office.  They  are  then  routed  through 
the  Secondary  Inventory  Control  Activity  (SICA)  ALC  to  the 
managing  agency  for  support.  The  SICA  ALC  is  the  ALC 
designated  to  represent  the  Air  Force  in  Healings  with  the 
agency  that  has  primary  responsibility  for  a  given  item. 

When  notification  of  positive  support  is  received,  D2  20  is 
updated  and  that  DCN  is  completed. 

Air  Force  Managed.  DCN's  for  items  that  are 
Air  Force  managed  are  output  from  D220  to  the  provisioning 
office  in  the  form  of  an  item  manager  review  document.  DCN's 
for  items  that  are  local iy  managed,  nr  prime,  are  sent  to  a 
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i  nra  i  item  nrnn-ijpr .  ''inn-prime  DC  Ns  for  i  t  ems  which  .ire  nor 
sfnr'K  i  isrpp  -ire  forwarded  fo  the  appropriate  lateral  ALC 
provisioning  office  where  they  are  handled  in  much  the  ^ame 
way  the  prime  items  are  handled.  Non-prime  DC Ns  for  items 
which  are  stock  listed  are  sent  direct i y  to  the  lateral  ALC 
hy  the  D220  through  the  AFLC  Responsive  Circuit  (ARC). 

The  item  manager  reviews  the  DC N  for  possible  impact  on 
existing  order  quantity  computat ions .  If  there  are  no 
previous  computations  then  an  initial  computation  is 
accomplished.  The  item  manager  updates  his  records  to 
reflect  any  changes  that  have  resuited  from  the  DCN.  A 
method  of  support  (MOS)  code  is  checked  or  assigned  by  the 
item  manager.  The  MOS  code  tells  D220  whether  or  not  the 
item  will  he  procured  on  a  Previsioned  item  Order  i'PIO)  . 

The  DCN  is  annotated  to  reflect  the  latest  buy  quantities  as 
required.  Buy  quantities  may  be  increased  or  decreased 
depending  on  the  nature  of  t‘ne  change  identified  by  the  DCN  . 
The  annotated  IM  review  do*,  ument  is  then  returned  to  the 
provisioning  office. 

If  a  cataloging  action  is  indicated,  t  he  provi s ioner 
forwards  the  IM  review  document  f n  the  cataloging  section. 
The  cataloging  ^periaiisrs  review  t he  DON  for  a  requirement 
for  a  National  Stock  Number  (NSN'i.  They  then  assign  a 
temporary  stock  number  and  initiate  the  assignment  or  a 
permanent  \S\.  The  DCN  i ^  annotated  with  the  temporary 
number  and  returned  to  the  provisioning  office. 


The  I  >1  rev  i  ew  document  updates  are  t  hen  inner  'n  '<■  •  ■, 

by  the  provisioner.  The  non  — prime  02/0  sends  t  he 
information  back  to  the  prime  D  2  2  fi  at  this  point  hv  wav  oj 
the  ARC  system.  DC  Ns  from  both  the  prime  and  non-prime  Ai.Cs 
should  be  back  in  the  prime  D22D  by  31  days  after  initial 
establishment  of  the  DCN  in  the  1)220.  Stage  3  takes  no  more 
than  2a  days. 

Depot  Team.  For  large  quantities  of  related  DCN s  T n  be 
accomplished  expeditiously,  a  depot  team  is  sometimes  formed 
to  perform  most  of  the  actions  required  in  Stages  2  and 
Team  members  include  a  provisioner,  an  equipment  speriaiist, 
an  item  manager,  and  a  cataloger.  DCN  conveyance  time 
between  each  of  these  disciplines  and  provisioning  is 
eliminated.  The  provisioner  annotates  the  fechni ra i  review 
document  with  inputs  from  all  participants  who  annotate 
their  own  copies  for  their  records.  Th e  provisioner  s r  1  ;  ' 
must  input  technical  review  data  to  D220  and  wait  for  an  l  >i 
review  document  before  inputting  the  IM  and  cataloging  data, 
bn f  the  depot  team  can  still  be  verv  effective  for 
nrnress ing  large  quantities  of  DCNs. 

stage  A .  The  D220,  having  been  updated  with  I M  uni 
cataloging  information,  next  outputs  a  PIO  review  1  is*- inn  r  o 
the  provisioner.  It  includes  additional  items  to  be 
procured  as  well  as  any  changes  that  might  have  .x-rurred  n. 
existing  Plus.  This  listing  is  sent  hv  the  pro  v  i  s  i  r>ne  r  to 
the  n r or n remen t  office. 


The  procurement  office  assigns  a  contract  modification 
number  (MOD— NP)  for  each  en+ry  in  the  review  list  and  then 
inputs  the  MOD-NP  direct  1"  to  the  GO 6 4  and  consequently  the 
D220.  This  is  the  only  stage  where  the  D220  is  updated  by 
someone  other  than  the  provisioner.  Stage  4  is  completed 
within  20  days. 

Stage  5.  Next  D220  cutouts  a  hard  copy  final  PIO  back 
ti  the  provisioner.  A  PIO  that  deletes  or  withdraws  a 
procurement  is  known  as  a  delete  PIO,  and  a  PIO  that 
procures  an  additional  item  is  known  as  an  add  PIO.  A  smaii 
change  to  an  item  often  results  in  a  delete  of  that  item  and 
an  add  of  the  "new''  slightly  changed  item.  The  provisioner 
matches  up  any  delete  PIOs  that  should  be  paired  with  any 
add  PIOs  so  they  wi i 1  be  processed  at  the  same  time.  They 
are  matched  so  the  contractor  will  not  receive  a  delete  PIO 
and  stop  work  only  to  find  that  an  add  PIO  was  coming  for 
the  same  basic  item.  Then  the  provisioner  forwards  the  PIO 
to  the  procurement  office  through  the  ALC ' s  Materiel 
Management  (MM)  funds  office.  MM  funds  tracks  soending  by 
weapon  system.  The  procurement  office  arranges  for  the 
printing  and  distribution  of  the  PIOs  to  the  contractor.  A 
copy  of  each  final  PIO  is  also  sent  back  to  provisioning. 
Stage  a  should  occur  within  o  days. 


T'ne  DCNs  were  analyzed  within  the  contpvt  nf  the 
contract  grouping  to  which  they  belonged.  Three  types  of 
contract  groupings  were  covered:  1)  the  entire  database  at 

WR-ALC ,  2)  twelve  selected  completed  contracts,  and  3)  a 
specific  program  by  itself,  LANTIRN. 

First,  the  three  contract  groupings  were  evaluated  for 
the  quantities  of  DC Ns  versus  the  number  of  line  items 
originally  submitted.  Next,  they  were  evaluated  for  their 
relative  quantities  of  the  seven  TOCCs.  Finally,  the 
LANTIRN  program  was  evaluated  for  the  numbers  of  ACNs  versus 
DC N s ,  and  procurable  versus  non-procurab 1 e  DC Ns .  Procurable 
DC  Ns  are  DCNs  submitted  against  items  that  were  original  i.v 
selected  for  procurement .  Non— procurab i e  DCNs  are  DCNs  that 
are  submitted  against  items  that  were  not  originally 
selected  for  procurement. 

Quantities  of  DCNs  Versus  Original  Data.  Figure  2 
displays  the  quantities  of  DCNs  submitted  per  100  original 
items.  The  entire  database  had  about  20  DCNs  per  LOO 
original  submittals,  and  LANTIRN  had  about  A3.  The 
completed  contracts  had  far  different  results.  They  had 
about  223  DCNs  per  100  original  items.  Original  data  were 
unavailable  for  three  of  the  twelve  completed  contracts,  hut 
of  the  remaining  nine,  six  had  more  DCNs  than  items 
original iv  submitted.  One  had  no  original  submissions  at 
all  and  two  others  had  icss  than  ten.  In  such  cases  it 


•appears  likely  that  DC  Ns  are  being  used  for  other  than  r'neir 


primary  purpose.  For  example,  a  small  program 
submitting  only  major  subassemblies  originally 
to  submit  all  of  the  components. 


might  approve 
and  use  DCNs 


By  TQCC,  The  different  TOC C s  and  their  relative 
percentages  of  total  DCN’s  per  contract  grouping  follows. 

The  results  are  presented  in  figure  3.  with  a  few 
exceptions  the  three  contract  groupings  all  had  the  same 
order  by  weight  of  the  seven  different  TOCCs. 

Additional  Item.  A  blank  TOCC  indicates  that  the 
DCN  is  written  to  initiate  an  additional  item  into  the 
provisioning  record.  Usually  a  DCN  with  a  blank  TOCC  is 
associated  with  and  replaces  a  DCN  with  a  delete  TOCC.  An 
additional  item  DCN  is  referred  to  as  a  "to"  and  a  deleted 
item  DCN  is  referred  to  as  a  "from”.  In  other  cases,  a 
blank  TOCC  means  that  a  completely  new  item,  a  fuse  for 
instance,  has  been  added.  Not  surprisingly,  blank  TOCCs 
were  the  single  most  common  of  the  change  codes  for  ail 
three  of  the  contract  groupings.  Between  40  and  30  percent 
of  ail  DCNs  studied  had  blank  TOCCs. 

Deleted  item.  A  TOCC  of  D  is  used  for  items  that 
are  to  be  deleted  f rom  the  provisioning  record.  D  is  the 
second  most  prevalent  TOCC  for  all  three  contract  groupings, 
ranging  from  24  to  42  percent.  LANTIBN  had  the  highest 
percentage  of  D  codes,  but  it  also  had  the  highest  number  of 
blank  cedes.  Note  that  upgrading  a  single  component,  a 
precision  resistor  to  replace  an  ordinary  resistor  for 
example,  requires  submittal  of  two  notices,  one  with  a  D  and 
one  with  a  blank  TOCC.  The  facts  that  Ds  and  blanks  are 
often  paired  together  and  that  the  two  represented  between 
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73  and  91  percent  of  aii  DCN’s  is  noteworthy, 
report  on  B— IB  parts  problems,  design  changes  and  design 
change  notices  are  used  interchangeably  (7:30).  They  are 
not  interchangeable.  If  a  single  part  changes,  two  notices 
are  likely  to  result. 

Modified  Item.  Modified  items  are  identified  by  a 
TOCC  of  M.  They  are  items  that  have  been  changed  as  opposed 
to  replaced.  The  change  may  result  either  from  engineering 
or  administrative  requirements.  The  compieted  contracts  had 
the  highest  percentage  of  modified  items  at  24.3  percent. 

The  WR-ALC  database  had  15,  and  LANTIRN  had  3  percent.  The 
modification  may  be  the  result  of  an  approved  engineering 
change,  or  it  may  have  resulted  from  an  administrative 
change  such  as  an  erroneous  data  entry  other  than  one  caused 
by  typographical  error. 

Quantity  Decrease.  A  TOCC  of  Q  indicates  a 
decrease  in  the  quantity  of  a  given  item  with  respect.  to  the 
end  item.  The  DCN  submitted  when  one  of  three  identical 
power  supply's  was  no  longer  needed  would  have  a  TOCC  of  Q. 
Quantity  decreases  represented  less  than  10  percent  of  the 
DC Ns  for  all  three  contract  groupings. 

Limited  Application.  Limited  application  changes 
are  TOCC  L.  Limited  application  changes  occur  when  a  part 
is  changed  that  only  applies  to  some  of  the  end  items.  For 
example,  the  first  50  aircraft  off  the  assembly  line  might 
have  one  avionics  system  while  the  next  50  nave  an  upgraded 


avionics.  The  avionics  systems  and  their  spare  parts  will 
now  have  iimited  application  to  the  serial  numbered  end 
items  they  came  with.  No  L  TOCCs  were  found  in  the 
completed  contracts  or  in  LANTIRN.  The  WR-ALC  database  had 
only  2.5  j_.fi.  ._._uit  1  i:i:i  Led  api-1  1  <z  « t  I  • ..  DC  Ns  . 

Typographical  Error.  Typographical  errors  are 
corrected  through  the  use  of  T  coded  DCNs.  All  three 
contract  groupings  had  less  than  two  percent  typographical 
change  DCNs.  This  is  important  in  light  of  the  fact  that 
AFLCM  65-33  stated  that  data  elements  changed  bv  the 
contractor  would  have  a  TOCC  of  T  (7:6-12,  6-13). 

Quantity  Increase.  A  quantity  increase  is 
identified  by  the  use  of  a  TOCC  of  A.  If  a  third  power 
supply  identical  to  two  others  was  added  to  a  system  that 
previously  had  only  the  two,  it  would  call  for  a  quantity 
increase  TOCC.  None  of  the  three  contract  groupings  had 
even  naif  of  a  percent  of  A  coded  DCNs. 


Additional 
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Blank  D  M  Q  L  T  A 


Figure  3  . 


Percentages  or  types  oE  Changes,  WP-ALC 


AC Ns  Versus  DC Ns. 


The  LANTIRN  program  was  pvqiuareci 
for  the  quantities  of  AC  Ns  versus  Drh's.  Administrative 
change  notices  (ACN)  occur  for  reasons  other  than  government 
approved  engineering  changes.  Errors  in  original  data 
submissions,  for  example,  would  result  in  ACNs  to  correct 
them  at  a  later  date. 

The  "traditional”  discriminator  based  on  AFLCM  65-33 
and  the  Air  Force  Addendum  is  that  ACNs  or  Change  Actions, 
(CAs)  are  identified  by  a  blank  Change  Authority  field  or  a 
TOCC  of  T.  That  is,  they  are  not  based  on  approved 
engineering  changes.  Using  the  ''traditional "  discriminator, 
only  three  percent  of  the  changes  submitted  on  LANTIRN  were 
ACNs  . 

The  weakness  of  using  a  blank  Change  Authority  field  to 
identify  ACNs  is  that  the  field  might  be  filled  incorrectly 
with  something  other  than  a  valid  approved  engineering 
change  number.  A  review  of  the  Change  Authority  fields  on 
the  LANTIRN  DC Ns  did  show  up  exactly  that:  inputs  other 

than  approved  engineering  change  numbers.  Instead  of 
correctly  identifying  the  authority  by  which  the  change  was 
made,  the  block  was  sometimes  filled  with  words  such  as 
''typo"  or  "  adm  i  n-chg .  "  No  guidance  was  found  that 
specifically  stated  what  kind  of  ''authority”  was  required 
for  the  Change  Authority  block  or  what  the  format  should  be, 
so  it  was  not  possible  to  validate  or  invalidate  every 
change  authority  number  for  LANTTRN.  Eliminating  only  the 


change  authoritv  codes  that  were  obviously  not  the  result  of 
approved  engineering  changes  increased  the  percentage  of 
LANTIRN  AC Ns  from  five  percent  to  nineteen  percent.  These 
are  considered  to  be  "not  traditionally  identified." 
Traditinnai lv  and  not  traditionally  identified  ACNs  are 
presented  in  Figures  A  and  o,  respectively. 


A  1 


F i gure  4 ,  Tr 


Procurable  Versus  N o n — p r o r u r a b i e .  The  purpose  of 
provisioning  data  is  to  provide  information  that  can  be  used 
to  select  and  procure  support  items  necessarv  to  operate  and 
maintain  the  end  item  for  some  initial  period  of  service 
(5:4).  If  a  change  is  made  to  a  non-procurab 1 e  support 
item,  one  that  has  not  been  selected  as  necessary  for  the 
ooeration  or  maintenance  of  the  end  item,  then  the  change 
wiii  be  much  less  important  to  the  provisioning  system  than 
if  the  item  had  been  procurable,  or  necessary.  MIL-STD- 
1561B  recognizes  this  and  places  a  reduced  time  requirement 
on  submittal  of  non-procurab 1 e  items  bv  the  contractor 
(5:13).  In  fact,  non-procurab i e  items  are  accepted  in  the 
form  of  a  listing  instead  of  on  formal  DCNs,  or  they  are  not 
required  at  ail.  LANTIPN  DCNs  were  reviewed  for  the  number 
submitted  against  non-procurab 1 e  items. 

Of  the  7,960  DCNs  in  the  LANTIPN  file,  1324,  almost  17 
percent,  weic  against  non-procurab i e  type  items.  The  17 
percent  were  made  up  primarily  of  delete  and  blan's  TOCCs. 
Other  than  their  being  for  non-procurab 1 e  items,  the  DCNs 
Mpoearcd  to  be  routine,  that  is,  made  up  primarily  of  add 
and  de i ei o  TOCCs .  It  appears  that,  qt  least  for  LANTIPN, 
changes  ro  non-procurab 1 e  items  may  be  being  submitted  the 
same  way  as  any  other  change  Procurable  versus  non- 
procijrable  DCNs  are  presented  in  Figure  6. 


o  n  -Procurables 


(  Broken  Out  by  TOCC  ) 


Figure  rS  .  LANTIRN  Non-procurable  OCX's 
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V  .  Conclusion*;  and  Recommendations 

Introduct ion 

The  purpose  of  this  research  was  to  describe  DCNs  and 
DcN  processing  in  the  Air  Force.  A  flow  chart  of  the  wav 
DCNs  are  currently  processed  was  developed  and  information 
about  the  quantities  and  different  types  of  Dt.Ns  submitted 
was  gathered.  This  chapter  contains  conclusions  and 
recommendations  based  on  the  information  gathered  as 
presented  in  Chapter  IV. 

The  Process  Phase 

The  review  of  the  process  phase  resulted  in  the 
development  of  the  process  flow  chart  presented  in  Figure  i. 

Conclusion.  It  was  thought  that  the  actual 
process  flow  might  vary  dramatically  from  one  ALC  to  the 
next.  This  did  not  turn  out  to  be  the  case.  Because  the 
D220  system  input  and  output  hard-copy  products  are  needed 
at  every  stage  in  the  process,  and  because  the  provisioning 
office  is  tasked  with  inpu+tirg  updates  and  routing  and 
tracking  output  documentation,  the  bulk  of  the  process  is 
fixed.  bn  f  or  t  una  t  e  1  v  ,  although  the  process  is  similar  from 
Al.C  to  ALC,  i+  is  not  adequately  described  in  the  Air  Force 
provisioning  policies  and  procedures  regulation.  For  the 
most  part,  the  provisioning  office  serves  as  an  i  ■  '  r  f  a  c  e 
hpfwppri  t  no  D2  2  0  computer  and  the  real  users  of  t  ne  data 
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such  us  equipment  specialists,  item  managers,  cat  a i  mrprs  and 
procurement  officers.  The  DON  passes  through  the 
provisioning  office  six  times  before  the  process  is 
complete.  This  time  consuming  and  labor  intensive 
processing  system  is  obviously  inefficient, 

Pecommendat ion .  The  computer  portion  of  the  D C N 
processing  system  should  be  improved  to  be  able  to  route  and 
track  its  own  products  and  allow  direct  screen  inputs.  Some 
improvements  could  be  made  to  the  D220,  but  it  is  now  frozen 
to  change  while  a  completely  new  system  is  developed  that 
will  rout*-  and  track  with  direct  screen  inputs  (14:1).  The 
need  for  such  a  system  is  indisputable  and  its  development 
and  implementation  should  be  a  high  priority  for  the  Air 
Force.  In  the  meantime,  process  changes  to  the  existing 
system  are  unlikely,  w'nat  can  be  done  now  is  to  better 
describe  the  existing  process  in  the  governing  regulations, 
particularly  AFLCP  800-9,  Air  Force  Provisioning  Policies 
and  Procedures,  in  hopes  tha,.  the  existing  procedures,  if 
better  understood,  will  work  more  smoothly.  The  process 
flow  chart  and  accompanying  explanation  in  Chapter  IV  should 
be  readily  a d a p t a b 1 e  to  AFLCP  800-9. 

The _Du t a  Phase 

The  Data  phase  of  the  research  first  provided 
quantities  of  DC Ns  versus  original  submittals.  Next  DC Ns 
wepe  broken  down  by  TCiCC,  AON  nr  DON,  and  Procurable  or  Non  — 
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procurable .  Relative  percentages  for  the  various  types  of 
DC Ns  were  provided  for  three  different  types  of  contract 
groupings:  the  entire  database  at  WR-ALC ,  selected  completed 
contracts,  and  a  specific  program  by  itself,  LANTIRN. 

Quantity  'versus  Initial  Submission.  This  phase  of  the 
research  attempted  to  describe  the  numbers  of  DCNs  likely  to 
occur  for  a  given  number  of  items  originally  submitted.  The 
results  are  graphically  presented  in  Figure  2. 

Conclusion.  There  is  no  apparent  dependent 
relationship  between  the  quantity  of  DCNs  and  the  quantity 
of  original  submittals.  Although  the  entire  database 
averaged  about  twenty  DCNs  per  hundred  original  data  items, 
and  LANTIRN  more  than  doubled  that  figure  to  44  per  hundred, 
the  completed  contracts,  at  228  DCNs  per  hundred  items,  were 
not  in  the  same  league.  The  extremely  high  numbers  for  the 
completed  contracts  appeared  not  to  realistically  represent 
a  typical  program.  Out  of  nine  completed  contracts  tested, 
six  had  more  DCNs  than  items  originally  submitted,  one  had 
no  original  submissions  at  all,  and  two  others  had  less  than 
ten.  It  makes  no  sense  that  changes  could  be  made  if  there 
were  no  data  to  begin  with. 

Recommendat ion.  It  is  not  proven  by  the  data 
submitted  here,  but  it  does  make  sense  intuitively,  that  20 
to  44  DC N s  could  be  expected  for  evorv  100  items  originally 
submitted.  Numbers  as  high  as  228  per  100  are  far  different 
and  hint  that  other  factors  may  be  at  work.  Since  one  of 


the  completed  contracts  had  no  original  items  at  ail,  and 


the  other  contracts  had  two  or  more  changes  submitted  on 
average  for  every  original  item,  it  becomes  apparent  that 
the  system  was  being  used  in  a  manner  inconsistent  with  that 
for  which  it  was  originally  intended. 

One  of  the  great  strengths  of  the  Air  Force  acquisition 
system  is  that  most  requirements,  processes,  and  regulations 
can  be  tailored  or  at  ieast  tempered  to  make  them  compatible 
with  the  specific  weapon  system  being  acquired.  Otherwise, 
there  would  be  no  need  for,  nor  advantage  to,  weapon  system 
management.  Still,  management  tools  like  the  provisioning 
system  are  not  uncomplicated  and  should  be  used  carefully. 
They  evolve,  slowly,  incrementally,  and  in  concert  with  many 
other  systems.  Imaginative  management  is  to  be  applauded, 
but  a  good  dose  of  caution  is  in  order  as  we l i . 

By  TOOT.  TOCCs  are  assigned  automatically  by  the  LSA 
software  as  described  in  MI L-STD- 1 388-2 A .  The  percentages 
of  the  different  Air  Force  TOCCs  for  the  three  contract 
groupings  are  presented  in  Figure  3. 

Conclusion.  There  is  little  difference  between 
programs  as  to  the  percentages  of  the  various  TOCCs  that 
will  be  submitted.  Blank  for  .dditional  items  and  D  for 
deleted  items  represent  by  far  the  majority  of  TOCCs 
submitted.  One  of  each  is  submitted  when  an  item  is  deleted 
and  another  item  takes  its  place;  this  represents  two  DC\’s 
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for  one  change.  Large  numbers  of  DCNs,  then,  can  represent 
much  smaller  numbers  of  actual  design  changes. 

That  the  relative  quantities  of  the  different  TOCCs 
appeared  comparable  for  all  the  contract  groupings  is  useful 
because  the  general  pattern  is  likely  to  be  repeated  for  any 
new  program.  Unfortunately,  the  description  in  the 
regulations,  of  the  different  TOCCs  and  how  they  are 
assigned,  is  so  obscure  as  to  make  the  information  about 
specific  codes  much  less  valuable  than  it  could  be.  The 
D22Q  does  not  use  a  TOCC  of  G  and  converts  Q  to  either  0  for 
quantity  decrease  or  A  for  quantity  increase.  Neither  AFLCR 
65-33,  AFLC  Provisioning  System  (D220)  Users  Manual,  nor 
AFLCR  800-9,  Air  Force  Provisioning  Policies  and  Procedures, 
explain  what  happens  to  TOCC  of  G  in  the  Air  Force  system, 
nor  do  they  ever  mention  the  Q  to  A  conversions.  A  TOCC  of 
T  for  typographical  error  is  so  seldom  used  as  to  be 
insignificant,  but  there  is  no  code  to  differentiate  the 
myriad  other  possible  types  of  contractor  errors. 

Recommendat ion ■  The  catch-all  name  of  DCN  should 
be  replaced  by  Provisioning  Data  Update  or  something  to  that 
effect.  This  is  much  less  confusing,  more  accurately 
represents  what  is  really  happening,  and  avoids 
misunderstandings  about  the  magnitude  of  design  changes  in 
Air  Force  acquisitions.  The  GAO  report  to  Congress  on  B-1B 
parts  pmhlems  misleadingly  stated  that  the  Air  Force  had 
received  187,500  design  changes  from  contractors  (7:30), 


These  were  really  DCN's,  not  necessarily  design  changes.  The 
actual  number  of  design  changes,  that  should  have  been 
reported  to  Congress,  was  certainly  much  less  than  what  was 
actually  reported. 

A  detailed  but  lucid  explanation  of  how  TOCCs  are 
"automatically"  assigned  should  be  included  in  MI L-STD- 1 388- 
2A.  Details  of  how  the  Air  Force  converts  MI L-STD- 1 366-2A 
TOCCs  to  the  codes  assigned  by  D220  should  be  included  in 
the  Air  Force  Addendum  and  in  AFLCM  65-33.  An  understanding 
of  exactly  how  the  TOCCs  are  assigned  is  needed  to 
understand  what  is  represented  by  any  given  TOCC,  For 
example,  it  is  very  interesting  to  note  that  less  than  two 
percent  of  all  DCN's  had  a  TOCC  of  T,  but  the  significance  is 
lost  if  there  is  no  way  to  tell  whether  a  quantity  increase, 
TOCC  Q,  was  due  to  an  actual  change  in  the  item  quantity  or 
was  due  to  a  typographical  error,  TOCC  T. 

MI L-STD- 1 386- 2A  and  the  associated  software  should  be 
changed  to  expand  the  definition  of  TOCC  T  to  include  any 
error  corrections  not  due  to  a  change  to  the  actual 
hardware.  This  is  one  wav  to  get  at  some  of  the  "why"  of 
changes  instead  of  just  the  "what.’'  It  is  honed  that 
knowledge  about  why  DCN's  are  occurring  will  lead  to  more 
proactive  management  and  eventually  to  fewer  DCN's  submitted. 

AC  Ns  versus  DCN's.  AC  Ns  are  changes  to  provisioning 
data  that  are  due  to  other  than  an  approved  change  to  the 
design.  The  percentage  of  LANTIRN  DCN's  that  are  due  to 


other  than  approved  changes  to  the  design  are  presented  in 
F i gure  4 . 

Conclusion.  The  LANTIRN  program  had  a  significant 
number  of  ACNs  submitted.  Using  the  guidance  in  the  Air 
Force  Addendum,  that  ACNs  can  be  identified  bv  a  blank 
change  authority  field,  there  were  only  three  percent  ACNs. 

A  closer  analysis  of  what  exactly  was  in  those  change  fields 
that  were  filled  revealed  that  many  were  filled  with 
information  other  than  what  was  expected.  At  least  nineteen 
percent  of  DC Ns  submitted  were  actually  ACNs.  ACNs  occur  in 
large  enough  quantities  (at  least  on  LANTIRN)  to  warrant 
different  processing  procedures. 

Recommend at  ion .  Only  the  LANTIRN  program  was 
evaluated  for  the  number  of  ACNs  submitted,  so  the  large 
numher  of  ACNs  submitted  could  well  be  LANTIRN  specific. 

The  change  authority  fields  on  a  larger  selection  of 
programs  than  just  LANTIRN  could  be  evaluated,  but  since  the 
guidance  on  what  ACNs  are  and  how  Change  Authority  fields 
should  be  filled  out  is  weak,  it  is  not  certain  that  further 
research  would  be  fruitful.  The  potential  for  large  numbers 
of  ACNs  on  any  program  is  already  clear.  ACNs  should  be 
addressed  immediately. 

The  first  step  is  to  strengthen  guidance  on  what  ACNs 
are  and  how  Change  Authority  fields  are  to  be  filled  out. 
MIL— STD— 1 06  IB  should  be  changed  to  be  compatible  with  MIL— 
STD— 1388-2A  in  addressing  updates  other  than  those  resuiting 


from  approved  changes.  As  recommended  earlier,  a  category 
such  as  Provisioning  Data  Updates  should  be  created  that 
includes  ACNs  as  well  as  DCNs.  The  Air  Force  Addendum,  MIL- 
STD-1 388-2A ,  and  AFLCR  800-9  should  be  changed  to  be  more 
specific  about  what  is  acceptable  in  the  change  authority 
field.  The  field  should  contain  only  the  number  of  the 
engineering  change  that  was  approved  by  the  government  and 
resulted  in  the  provisioning  data  change.  If  the  change  was 
due  to  other  than  an  approved  engineering  change,  the  Change 
Authority  field  should  be  left  blank. 

Since  ACNs  are  not  due  to  approved  changes  to  the 
design,  it  is  reasonable  to  assume  that  they  are  much  less 
likely  to  affect  buy  quantities  of  support  items  than  DCNs 
which  are  due  to  actual  design  changes.  Changes  that  do  not 
affect  support  item  buys  are  not  significant  to  the 
provisioning  process.  Some  ACNs  however,  may  impact 
existing  procurement  actions  or  prompt  new  procurement 
actions.  Those  that  do  have  an  impact  should  be  separated 
from  those  that  do  not.  Provisioning  specialists  may  be 
able,  in  many  cases,  to  judge  which  ACNs  will  or  will  not 
affect  procurement,  but  they  do  not  nave  the  experience  nor 
the  authority  to  make  that  decision.  It  is  the  equipment 
specialist  and  item  manager  that  are  ultimately  responsible, 
so  they  must  make  the  actual  decision.  However,  if  all  ACNs 
must  be  routed  through  the  equipment  specialist  and  item 
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manager , 


rhe  process  is  the  same  as  that  for  D C N s ,  and  the 


advantage  of  separating  AC Ns  from  DC Ns  is  lost. 

The  problem  might  be  overcome  by  the  development  of  a 
simple  yet  formal  decision  rules  table  similar  to  that  shown 
in  Table  2.  For  example,  if  the  part  number  does  not 
change,  and  key  named  data  fields  do  not  change,  then  no 
further  action  is  needed;  if  the  part  number  is  changed,  the 
kev  fields  are  not  changed,  and  procurement  of  the  original 
part  number  has  already  been  initiated,  then  only 
procurement  need  be  involved;  and  so  forth. 


Table  2.  ACN  Decision  Rules  Tabie 


Ru  1  c. 

Act  ion 

■  A 

-  part  number  changed 
i  part  number  not  changed 

B 

i  c 

B 

key  data  not  changed 
key  data  changed 

1  Forward  PIG  rev  doc 
Forward  Tech  rec  doc 

c 

key  data  not  changed 
key  data  changed 

No  Act i on 

D 

D 

'  existing  PIG 
no  existing  PIG 

'  Forward  PIG  rev  doc 

No  A c t i o n 

With  such  a  table  in  hand, 

the  provisioner  would 

initiate  further  processing  of  only  those  ACN's  that  affect 
provisioning  and  would  initiate  that  processing  at  the  stage 
indicated.  In  the  case  of  only  procurement  being  involved, 
the  provisioner  would  enter  the  technical  review  and  IM 
review  documents  with  no  changes  and  would  forward  only  the 


PIO  review  document  direct iv  to  the  procurement  office.  The 
decision  rules  table  development  might  best  be  managed  by 
the  Headquarters  Provisioning  Policy  office,  in 
collaboration  with  the  five  ALCs.  The  ALCs  could  provide 
the  inputs  and  coordination  of  the  various  disciplines 
involved,  particularly  the  equipment  specialist  and  item 
management  offices.  By  formally  including  the  equipment 
specialist  and  item  management  offices  in  the  decision  rules 
table  development,  including  the  designation  of  key  data 
fields,  the  authority  problem  might  be  overcome. 

Procurable  Versus  Non— procurab 1 e ,  DCNs  for  n on- 
procurable  items  are  of  no  consequence  to  a  provisioning 
system  that  exists  to  procure  initial  spares.  The  number  of 
DCNs  submitted  for  non-procurahle  items  relative  to 
procurable  items  is  presented  in  Figure  5. 

Conclusion ■  DCNs  for  non-procurabie  items 
represented  over  six+een  percent  of  the  DCNs  submitted 
against  LANTIPN.  If  there  is  a  policy  that  DCNs  for  non- 
procurabie  items  should  not  be  submitted,  it  is  not  being 
universally  followed.  Like  ACNs  that  have  no  effect  on 
provisioning,  DCNs  for  non-procurabie  items  have  no  effect 
on  provisioning. 

Re commend at  ion.  Ensure  that  contractors  are 
directed  not  to  submit  DCNs  for  non-procurab 1 e  items  unless 
the  change  is  such  that  the  item  is  now  recommended  for 
procurement.  For  example,  if  a  non-procurabie  item  is  being 


slightly  modified,  a  DON  should  not  hr  submitted,  if  i  t 

is  he  i  n  cr  modified  to  the  point  that  it  should  now  be  a 
procurable  item,  a  DON  s'nouid  be  submitted.  Ideally,  a  D220 
edit  should  be  written  to  ignore  DCN's  that  are  for  non- 
procurable  items,  but  D220  changes  are  not  being  made 
because  of  the  new  provisioning  system  that  is  being 
developed.  When  DONs  for  non-procurab i e  items  are  submitted 
to  the  provisioning  office,  further  processing  should  not  be 
initiated. 

General  Discussion.  Updates  to  provisioning  data  can  be 
categorized  by  TOCO,  they  can  be  categorized  as  resulting 
from  either  administrative  or  engineering  changes,  and  they 
can  be  categorized  as  affecting  procurable  or  non-procurab 1 e 
items.  These  categories  can  be  exploited  to  increase  the 
efficiency  of  DON'  processing,  and  recommendations  nave  been 
made  to  that  e f fort .  In  each  case  the  category  that  is  most 
important  to  provisioning  is  emphas i zed  and  the  cat  ego ry 
least  important  is  de-empha s i zed . 

A  single,  broader,  simpler  category  might  be 
appropriate.  DCNs  could  be  segregated  only  by  whether  they 
affect  provisioning  or  do  not  affect  provisioning.  Ail  the 
fields  of  a  DCN,  Change  Authority,  TOCC,  and  the  rest  would 
be  used.  A  decision  table  like  the  one  recommended  for 
processing  ACNs,  only  far  more  detailed,  would  have  to  be 
developed.  DCNs  that  1  not  affect  provisioning  would  never 
be  output  for  processing.  This  type  of  categorization  would 


be  complex  and  would  almost  have  to  be  computerized.  In  the 
long  term,  the  segregation  could  be  included  in  the  software 
of  the  new  provisioning  system  currently  under  development. 
By  developing  the  smali  scope,  manual  decision  rules  table 
for  ACNs,  the  feasibility  of  program  encompassing  all 
updates  could  be  demonstrated  or  discredited. 

■Summary 

The  process  flow  documented  is  not  subject  to 
significant  improvement  because  the  baseline  on  the  D22Q 
system  it  supports  is  frozen.  Opportunity  does  exist  to 
document  the  process  in  the  provisioning  policy  and 
procedures  regulation. 

N’o  relationship  between  the  number  of  original 
submittais  and  the  number  of  DCNs  was  discovered,  but 
programs  managed  in  accordanoe  with  existing  policies  and 
procedures  would  be  expected  to  have  considerably'  less  than 
a  one  to  one  ratio. 

The  most  common  DCNs  are  to  delete  items  and  to  add 
items.  Often  the  deletion  and  addition  are  for  the  same 
design  change,  so  the  number  of  design  changes  is 
substantially  less  than  the  number  of  DCNs. 

The  general  category,  DCNs,  should  be  renamed  and 
should  include  updates  resulting  from  changes  to  the  design, 
DCNs,  as  well  as  those  not  resulting  from  a  change  +o  the 
design,  ACNs.  ACNs  appear  to  be  of  large  enough  frequency 


to  warrant  development  of  their  own  special  procedures.  A 
decision  rules  table  might  be  helpful  for  AC\'  processing. 

A  significant  number  of  DCNs  for  non-procurab 1 e  irems 
are  being  submitted,  apparently  unnecessarily.  DCNs  for 
non-procurab 1 e  items  do  not  impact  provisioning  and  should 
not  be  submitted  nor  processed. 

DCNs  could  be  segregated  into  two  categories:  either 
they  affect  provisioning  or  they  do  not.  Those  that  do  not 
should  not  oe  processed.  Software  should  be  developed  as  a 
part  of  any  new  provisioning  system  that  could  identify  and 
edit  out  changes  that  do  not  impact  provisioning. 
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begin  with. 

This  research  describes  DCNs  and  DCN  processing  in  the 
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